Many techniques for supporting network processing are known. Such techniques include generic memory management, interrupt scheduling, state machines, computer program code generation, and multi-protocol interfaces. The foundations of such threads are generally understood but in many cases their practical realization has fallen short of the desired results.
Today many computer programs are intended to be processed in multi-processor and/or multi-threaded environments. The term processing is typically associated with executing a thread (such as a computer program or set of computer program instructions) and is generally considered to be an operating system concept that may include the computer program being executed and additional information such as specific operating system information. In some computing environments executing a computer program creates a new thread to identify, support, and control execution of the computer program. Many operating systems, such as UNIX, are capable of running many threads at the same time using either a single processor and/or multiple processors. Multiple processors can perform tasks in parallel with one another, that is, a processor can execute multiple computer programs interactively, and/or execute multiple copies of the same computer program interactively. The advantages of such an environment includes a more efficient and faster execution of computer programs and the ability of a single computer to perform multiple tasks concurrently or in parallel.
A multiprocessor system, such as for example a network processor system, may include a number of system-on-chip components, that may be optimized for specific processing, such as for example optimized for processing packet input-output and packet modification. A packet may include a variety of information, including for example, a data item, a packet destination address, and a packet sender address. Support for processing a high volume of packets may be provided by a multiprocessor system that requires improvements in common operating system functions. In part due to the high volume of packets, a multiprocessor system is particularly susceptible to inefficient processing techniques that may otherwise be effective with a single processor system.
Computer program instructions are typically processed by a CPU within one or more thread contexts, such as for example a regular context and a limited context. The CPU can execute a variety of different types of computer program instructions. The execution of these different types of computer program instructions may be limited to a regular context and/or a limited context. A set of computer program instructions may be coupled with either a regular context or a limited context. If the set of computer program instructions are coupled with a regular context then the CPU may execute those computer program instructions from the set of computer program instructions that correspond with the regular context. If the set of computer program instructions are coupled with a limited context then the CPU may execute those computer program instructions from the set of computer program instructions that are coupled with the limited context. According to one embodiment of the present invention the regular context may be referred to as a so-called “user mode”, and the limited context may be referred to as a so-called “kernel mode”.
A regular context is typically coupled with the computer program instructions of a user application, while the limited context is typically coupled with the computer program instructions of an interrupt. The regular context typically support processing most computer program instructions. The regular context is typically used for most processing activities, including activities that may block a caller, such as for example semaphores, memory allocation, freeing allocated memory, and/or input and output processing.
A limited context is typically coupled with the computer program instructions of privileged computer programs, such as for example scheduling computer programs and interrupt service routines. The limited context typically restricts some processing activities, such as for example not allowing processing activities that may block a caller, such as semaphores, memory allocation, freeing allocated memory, and/or input and output processing. The limited context may also supports processing additional computer program instructions, such as for example additional computer program instructions for scheduling and interrupt service routines.
Most processing typically occurs in the regular context, while processing of interrupts typically occurs in the limited context, which limits the processing activities that may be performed. Processing interrupts in conventional operating system provides that corresponding interrupt service routines (ISR) are processed in a limited context and restrict the use of many processing activities and/or computer system services typically available in the regular context. The restrictions of a limited context thereby protects the system against a variety of potential problems, such as deadlock scenarios, and scheduling conflicts. A potential deadlock scenario may include two or more threads that are attempting to obtain exclusive access to the same shared resource, wherein the threads may obtain partial access. Consequentially, neither thread obtains exclusive access and the threads are deadlocked. A potential scheduling conflicts may include the inability to schedule individual threads because the active thread may be performing a processing activity that prevents scheduling, such as a semaphore. Unfortunately, this type of processing activity is often required to effectively implement ISRs.
Further, ISRs may be used in scheduling threads for processing on one or more processors. In a conventional multiprocessing system an ISR typically interrupts a thread without regard to the specific processing activity currently being performed. Ideally, the thread may be executing in an interruptible state or in an uninterruptible state and the thread would only be interrupted while the thread is in the interruptible state. Unfortunately, ISR processing does not take into consideration whether a thread is in an interruptible state or an uninterruptible state.
Additionally, the processing associated with an ISR is static in nature such that an identical function is performed for a given signal or interrupt. Ideally, the functionality associated with an ISR would be dynamically configured based on information available to a multiprocessor system. Unfortunately, conventional interrupt processing is statically defined and can not be dynamically defined or redefined.
Therefore conventional processing of interrupts is not efficient and there remains a need for a system, method, computer program, and computer program product for interrupt scheduling in processing communications. What is needed is an ability to processing signals, that may correspond with interrupts, within a regular context to improve the flexibility of processing associated with both signals and interrupts. Further, a need exists for an ability to further improve the integrity of processing associated with a given thread such that interrupts are preferably processed while the thread is in an interruptible state, supporting dynamically defining and redefining interrupts, and that overcomes the above and other disadvantages of known interrupt processing.